Fix #10605: Avoid mismatched constraints when prototypes are context … #10916
Conversation
…text functions Fixes scala#10605
| @@ -632,7 +632,7 @@ object ProtoTypes { | |||
| normalize(et.resultType, pt) | |||
There was a problem hiding this comment.
Just to be sure, adding the followIFT argument will only affect the fall through case and will be dropped for recursive calls. Is this intended?
There was a problem hiding this comment.
Yes, because all recursive normalize calls are against the same pt, which determined the value of followIFT.
There was a problem hiding this comment.
I just wondered whether the check can be inlined at 635 to
if iftp.exists && !defn.isContextFunctionType(pt) then ...to avoid this additional argument. But this would not be a semantics preserving refactoring since the argument followIFT defaults to true for the next recursive call.
| val ptw = pt.widenExpr | ||
| necessarySubType(tpw, ptw) || tpw.isValueSubType(ptw) || viewExists(tp, pt) | ||
| val tpn = normalize(tp, pt, followIFT = !defn.isContextFunctionType(pt)) | ||
| necessarySubType(tpn, pt) || tpn.isValueSubType(pt) || viewExists(tpn, pt) |
There was a problem hiding this comment.
Sorry for so many questions on such a simple PR. But I noticed that you don't widen pt here anymore. Can't this change the result of comparing the types for other examples?
There was a problem hiding this comment.
In theory it could, but in practice it did not. Conceptually, the correct thing is not to widen here, so unless we see an example where it causes a problem that should be the default.
…functions
Fixes #10605